Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-095.TXT

Text File | 1992-06-30 | 77.1 KB | 2,062 lines

C.S.M.P. Digest             Tue, 26 May 92       Volume 1 : Issue 95

Today's Topics:

    How do I find out if Multi-finder is running??


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The digest is a collection of articles from the internet newsgroup comp.sys.
mac.programmer.  It is designed for people who read c.s.m.p. semi-regularly
and want an archive of the discussions.  If you don't know what a newsgroup
is, you probably don't have access to it.  Ask your systems administrator(s)
for details.  (This means you can't post questions to the digest.)

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (C J Hall)
Subject: How do I find out if Multi-finder is running??
Date: 17 Feb 92 15:36:52 GMT
Organization: School of Mathematics, University of Bath, UK

Hi,
    Sorry if this is a FAQ, but I would like to be able
to determine whether or not multi-finder is running or not.
I am hoping that all I have to do is just test a global flag,
or similar.
Thanks in advance

Chris

- --------------------------------------------------------
Chris Hall is [e-mail]
 " As ye live by the sword so shall ye die by the sword."
- --------------------------------------------------------



- -------------------------

From: [e-mail] (Nick Rothwell)
Subject:  How do I find out if Multi-finder is running??
Date: 17 Feb 92 17:22:43 GMT
Organization: Friends of the Salter Duck

Yes, it is (or, at least, was) a FAQ.

MultiFinder is not "running" - it is obsolete.

System 7.0 is always running. To all intents and purposes, that provides
MultiFinder. The answer to your question is therefore "always."

(If you're only using System 6.0, I'd advise you to regard MultiFinder as
always running as well - software which can't handle it is doomed to
obsolescence.)

Final point: why do you want to know? I've *never* heard anybody give
me a convincing reason. It's like saying, "is there a flag which tells
me whether there are any Post-It notes attached to the case of this
Macintosh?" Why does it matter?

Nick.
--
Nick Rothwell, LFCS, Edinburgh | "Chai ch t'chai ch't chnna chnna chnna ch'th
             [e-mail] |  Chai ch t'chai ch't chuth chena chann ch'tt
Mentation Consultancy Services |  Chie ch t'chie ch t'chaaa chn chattr chattr"
   [e-mail] |       -- Wavestation, V3 software, my dragon.



- -------------------------

From: [e-mail] (David Castell)
Subject:  How do I find out if Multi-finder is running??
Date: 18 Feb 92 15:05:35 GMT
Organization: Computer Systems Group

In article <[e-mail]>, [e-mail] (Nick Rothwell) writes:
>
> Yes, it is (or, at least, was) a FAQ.
>
> MultiFinder is not "running" - it is obsolete.
>
> System 7.0 is always running. To all intents and purposes, that provides
> MultiFinder. The answer to your question is therefore "always."
>
> (If you're only using System 6.0, I'd advise you to regard MultiFinder as
> always running as well - software which can't handle it is doomed to
> obsolescence.)
>
> Final point: why do you want to know? I've *never* heard anybody give
> me a convincing reason. It's like saying, "is there a flag which tells
> me whether there are any Post-It notes attached to the case of this
> Macintosh?" Why does it matter?
>
> Nick.
> --

I have to disagree with your assessment that MultiFinder is obsolete.  When
dealing with the educational market, we always have to be aware of the many
schools out there who are still running 1 meg Mac Pluses off of floppies.
(Some are actually still using 512e's with system 4).  Most of these people
are still using the Finder and don't want to switch to MultiFinder.

In the past I have had to tell whether MultiFinder is running, so I guess
I might as well give you a chance to shoot down my reason :)
I wanted to have the ability for one workstation on the network force the
launch of a program on other workstations (eg. a teacher might want to have
all machines load a program for the next class).  However, the workstation
code should not attempt a launch if MultiFinder is not running and the
Finder is not the currently running program.  Otherwise, someone might be
in Word and lose their work when I launched.  If MultiFinder was running it
would not matter if someone was using Word because it would still stay
running after the launch.  In general, I agree with you that it doesn't
matter which is running.  However, I have found launching to be an exception.

I response to the original poster:  There is an easy way to determine if
MultiFinder (or the multi-program environment of System 7) which I have
never seen described elsewhere .  Just check to see if trap $A88F is
implemented.  This trap was called 'JugglerDispatch' under MultiFinder and
is now officially 'OSDispatch' under System 7.  It is unimplemented in the
Finder.

Now that you have the ability to tell what is running, I want to second
Nick's advice.  Please don't write software that only runs under Finder.
If your program does not work under MultiFinder or insists that only the
Finder can run, it is useless.

Dave Castell
Computer Systems Group



- -------------------------

From: [e-mail] (Scott Lindsey)
Subject:  How do I find out if Multi-finder is running??
Date: 18 Feb 92 22:02:21 GMT
Organization: Claris Corporation

In article <[e-mail]>, [e-mail] (David Castell) writes:
>
> I response to the original poster:  There is an easy way to determine if
> MultiFinder (or the multi-program environment of System 7) which I have
> never seen described elsewhere .  Just check to see if trap $A88F is
> implemented.  This trap was called 'JugglerDispatch' under MultiFinder and
> is now officially 'OSDispatch' under System 7.  It is unimplemented in the
> Finder.
>

It's documented in the MultiFinder programmer's guide (or whatever it was called).
In there, it's described as _MFMemoryTrap, through which you can get temporary
memory in MultiFinder's heap.  Here's how I check for it:

    Boolean MultiFinder;

    if (!Gestalt(gestaltOSAttr, &response))
        MultiFinder = !!(response & 1<<gestaltTempMemSupport);
    else    // Gestalt said no.
        MultiFinder = TrapIsImplemented(_MFMemoryTrap);


--
Scott Lindsey <[e-mail]>



- -------------------------

From: [e-mail] (Nick Rothwell)
Subject:  How do I find out if Multi-finder is running??
Date: 19 Feb 92 11:40:49 GMT
Organization: Friends of the Salter Duck

In article <[e-mail]> [e-mail] (David Castell) writes:

   I have to disagree with your assessment that MultiFinder is
   obsolete.

Maybe I should rephrase: software which can't deal with MultiFinder is
dooming itself to obsolescence. All my code will happily run without
MultiFinder (or System 7.0), but if that was a requirement, it would
be useless.

   In the past I have had to tell whether MultiFinder is running, so I guess
   I might as well give you a chance to shoot down my reason :)

OK, fire away...

   I wanted to have the ability for one workstation on the network
   force the launch of a program on other workstations (eg. a teacher
   might want to have all machines load a program for the next class).
   However, the workstation code should not attempt a launch if
   MultiFinder is not running and the Finder is not the currently
   running program.  Otherwise, someone might be in Word and lose
   their work when I launched.

OK, what you're after here is a "can I safely launch other programs"
test. Now, I'm not going to suggest that there should be traps for
every such thing (or "will a DA have its own layer" or "are the desktop
icons always visible" or ...) but the general point is that you're
after specific information about the environment, and you don't
actually want to know about MultiFinder running at all. Suppose, for
example, it were possible to queue a launch under UniFinder for when
something else quits. Then, testing for MultiFinder would be the wrong
thing to do in your case.

Nick.
--
Nick Rothwell, LFCS, Edinburgh | "Chai ch t'chai ch't chnna chnna chnna ch'th
             [e-mail] |  Chai ch t'chai ch't chuth chena chann ch'tt
Mentation Consultancy Services |  Chie ch t'chie ch t'chaaa chn chattr chattr"
   [e-mail] |       -- Wavestation, V3 software, my dragon.



- -------------------------

From: [e-mail] (Quinn "The Eskimo!")
Subject:  How do I find out if Multi-finder is running??
Organization: The University of Western Australia
Date: Thu, 20 Feb 1992 01:24:11 GMT

In article <[e-mail]>, [e-mail] (Nick Rothwell) writes:
>
> In article <[e-mail]> [e-mail] (David Castell) writes:
>
>    However, the workstation code should not attempt a launch if
>    MultiFinder is not running and the Finder is not the currently
>    running program.  Otherwise, someone might be in Word and lose
>    their work when I launched.
>
> OK, what you're after here is a "can I safely launch other programs"
> test.

How about testing the gestaltLaunchCanReturn bit of the response from
the gestaltOSAttr selector.  It works for MultiFinder 6.0.5 and greater
(I think - it definitely works on >= 6.0.7) (be wary of MultiFinder
6.1b9 though).

Quinn "The Eskimo!"   <[e-mail]>   "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia




- -------------------------

From: [e-mail] (Pete Gontier)
Subject:  How do I find out if Multi-finder is running??
Date: 20 Feb 92 01:54:58 GMT


 DC> From: [e-mail] (David Castell)

 DC> I response to the original poster:  There is an easy way to determine if
 DC> MultiFinder (or the multi-program environment of System 7) which I have
 DC> never seen described elsewhere .  Just check to see if trap $A88F is
 DC> implemented.  This trap was called 'JugglerDispatch' under MultiFinder
 DC> and is now officially 'OSDispatch' under System 7.  It is unimplemented in
 DC> the Finder.

Jeez, I think I know too much about this topic, both good and bad.

1.bad) Yes, this method is acknowledged by Apple employees. The acknowledgement takes the form: "You might be tempted to do this, but don't. We might implement _OSDispatch under UniFinder just to foil this strategy." I've heard this so far from two who shall go nameless. (I don't know how the Apple Internal Thought Police operate.)

2.good) Aside from just hoping that this undocumented behavior stays this way forever, you might take some comfort in knowing that all sorts of Apple programs check for MultiFinder this way. Does this make it any better a practice? No. Apple has all sorts of opportunity to fix these naughty programs because of course they know before everyone else when the System is about to be updated. So they have special privelege. However, tracking down all the instances of such stuff would not be any fun.

3.bad) The last time I discussed this strategy in public, one of the System 7
teamsters piped up and assured me that although this strategy was against
the rules, it would probably work forever, because there most likely would
never be a System 6.0.8. Two months later, there was. Even worse: MacWeek
made noise recently about the next generation of low-end machines
running something akin to System 6.0.9 -- which supposedly will implement
some System 7 functionality (hope y'all've been calling Gestalt like good
little boys and girls). With changes like that, _OSDispatch could easily be implemented under UniFinder. (So I suppose #2 isn't such a reassurance after
all, eh?)

4.weird) I once heard here on UseNet that calling PtrZone on the window
manager port was fairly educational -- if it doesn't live in your app's
zone, you've got MultiFinder. Never tried it, though.
 * Origin: EC Technology, Santa Barbara, CA (1:109/70.811)



- -------------------------

From: [e-mail] (Jeremy Roussak)
Subject:  How do I find out if Multi-finder is running??
Date: 20 Feb 92 21:40:07 GMT
Organization: Computer Science Dept, QMW, University of London

In <[e-mail]> [e-mail] (Pete Gontier) writes:

>4.weird) I once heard here on UseNet that calling PtrZone on the window
>manager port was fairly educational -- if it doesn't live in your app's
>zone, you've got MultiFinder. Never tried it, though.

I've used this for an INIT: it works very well.  The only catch
is that DA Handler runs with TheZone set to SysZone, so
PtrZone(WMgrPort) does equal TheZone.

Jeremy Roussak



- -------------------------

From: [e-mail] (Larry Rosenstein)
Subject:  How do I find out if Multi-finder is running??
Date: 25 Feb 92 03:11:26 GMT
Organization: Taligent Inc.

Before discussing the pros and cons, it is important to understand why the
"party line" is that you should never test for MultiFinder running.  Answering
the question "Is MultiFinder running?" only answers that question.  But in 99%
of the cases, the REAL question that people want answered is something else.
(For example, "Will the _Launch trap return?")

People assume that answerin the question about MultiFinder IMPLIES the answer to
the other question.  Making assumptions like this is a major source of
incompatibilities.  (How many programs have broken because they assumed that Mac
II-like machine implies a machine with an FPU?)

In article <[e-mail]>,
[e-mail] (Pete Gontier) writes:
>
> 1.bad) Yes, this method is acknowledged by Apple employees. The
acknowledgement takes the form: "You might be tempted to do this, but don't. We
might implement _OSDispatch under UniFinder just to foil this strategy."

I think testing for MultiFinder temporary memory (which I believe is different
from testing for the trap) is probably the best way to determine if MultiFinder
is running.  Testing the zone containing the WmgrPort, or looking at the Apple
menu is probably a bad way.

> the rules, it would probably work forever, because there most likely would
> never be a System 6.0.8. Two months later, there was. Even worse: MacWeek

6.0.8 is the exact same system; only the printer drivers changed.

I don't think Apple would implement the MultiFinder trap just to screw up
people, but WaitNextEvent started out as MultiFinder-only and then was
implemented all the time.

The most important thing, however, is to recognize what kind of assumption you
are making (whether it's based on the existence of the MultiFinder trap or the
zone containing WmgrPort), and decide for yourself the chance of that assumption
being violated in the future.  The same advice applies when writing INITs or
patching traps.
--
Larry Rosenstein
[e-mail]




- -------------------------

From: [e-mail] (Kent Borg)
Subject:  How do I find out if Multi-finder is running??
Organization: Camex Inc., Boston MA
Date: Sun, 01 Mar 1992 12:56:14 EST

In article <[e-mail]> [e-mail] (Larry Rosenstein) writes:
>(How many programs have broken because they assumed that Mac
>II-like machine implies a machine with an FPU?)

A "Fun Fact" I can't resist posting.  As I sit here typing on an
FPU-less 140, with an FPU-less IIsi two feet away, I am quite sure I
once heard an Apple Engineer on the podium at a Developers' Conference
say that all future '020-or-better Macs would have math chips.  He was
wrong.

Why post this?  First, because poking fun is fun, but second to try to
enhance the sense of paranoia which should be in everybody who
programs Macintoshes.  What assumptions are you making?  How many of
them will be proved bad?

--
Kent Borg                            internet: [e-mail]   AOL: kent borg
                                            H:[phone]  W:[phone]
"Eating healthy beef is not healthful, the steer will take offense at you
chewing on his flanks."      -me



+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 8 Mar 92 01:46:52 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Kent
Borg) writes:
>
> In article <[e-mail]> [e-mail] (Larry Rosenstein) writes:
> >(How many programs have broken because they assumed that Mac
> >II-like machine implies a machine with an FPU?)
>
> A "Fun Fact" I can't resist posting.  As I sit here typing on an
> FPU-less 140, with an FPU-less IIsi two feet away, I am quite sure I
> once heard an Apple Engineer on the podium at a Developers' Conference
> say that all future '020-or-better Macs would have math chips.  He was
> wrong.

The unofficial and official DTS standpoint is that *never* assume that
an FPU is installed. Use Gestalt to check for this, now and forever.

Cheers,
Kent

- ----
- --
Kent Sandvik - Apple DTS  - Dynamic Language Evangelist
[e-mail]
All opinions expressed are my own, and not related to any company or
organization.
Happy, happy, joy, joy!

+++++++++++++++++++++++++++

From: [e-mail] (Nick Rothwell)
Date: 12 Mar 92 12:38:59 GMT
Organization: Friends of the Salter Duck

In article <[e-mail]> [e-mail] (Kent Sandvik) writes:

   The unofficial and official DTS standpoint is that *never* assume that
   an FPU is installed. Use Gestalt to check for this, now and forever.

Er, but: can you always assume that *Gestalt* is installed on all
machines? :-)

Nick.
- --
Nick Rothwell, LFCS, Edinburgh |         Tips to confuse a vegetarian #6:
             [e-mail] |           serve a venus flytrap salad.
Mentation Consultancy Services |
   [e-mail] | ("You mean it's a vegetable but it eats meat?")

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Organization: The Royal Society for Putting Things on Top of Other Things
Date: Thu, 12 Mar 1992 18:01:31 GMT

In article <[e-mail]> [e-mail] (Nick Rothwell) writes:
>In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
>
>   The unofficial and official DTS standpoint is that *never* assume that
>   an FPU is installed. Use Gestalt to check for this, now and forever.
>
>Er, but: can you always assume that *Gestalt* is installed on all
>machines? :-)

The _Gestalt glue checks for the presence of the trap, and emulates many
functions, including the FPU check, even if the trap is absent.  You can
also use _SysEnvirons.  And if _SysEnvirons isn't available then you're
working with a hopelessly out-dated version of the system.

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s+(+) e+ h- pv   |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Thu, 12 Mar 1992 21:22:52 GMT

[e-mail] writes:
>
>The _Gestalt glue checks for the presence of the [Gestalt] trap...

Only if you're in MPW, remember.  Think C users must do the check.
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Organization: The Royal Society for Putting Things on Top of Other Things
Date: Thu, 12 Mar 1992 22:06:42 GMT

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:
>[e-mail] writes:
>>
>>The _Gestalt glue checks for the presence of the [Gestalt] trap...
>
>Only if you're in MPW, remember.  Think C users must do the check.

As far as I am aware, the THINK languages use Apple's (MPW) Toolbox interface
glue.  If you're running the latest versions of THINK C or THINK Pascal,
you do in fact have the _Gestalt glue that checks for the presence of the
trap.

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s+(+) e+ h- pv   |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Organization: Kalamazoo College
Date: Fri, 13 Mar 1992 00:17:42 GMT

[e-mail] writes:
>[e-mail] (Jamie R. McCarthy) writes:
>>[e-mail] writes:
>>>
>>>The _Gestalt glue checks for the presence of the [Gestalt] trap...
>>
>>Only if you're in MPW, remember.  Think C users must do the check.
>
>As far as I am aware, the THINK languages use Apple's (MPW) Toolbox interface
>glue.  If you're running the latest versions of THINK C or THINK Pascal,
>you do in fact have the _Gestalt glue that checks for the presence of the
>trap.

I don't think so.  I tested this a few months ago with ThC 5.0.2 and the
then-current MPW headers, and I just tried again with the current (4 Dec
1991) GestaltEqu.h.  The "Mac #includes" shipped in the box doesn't
#define either SystemSixOrLater or SystemSevenOrLater, so it's not
leaving out the tests because of that.

With <MacHeaders> in the prefix, I gave the disassembler:

#include <GestaltEqu.h>
int fred(void);
int fred()
{
    OSErr theOSErr; long r;
    theOSErr = Gestalt(gestaltMachineType, &r);
}

...and it told me:

00000004        CLR.W     -(A7)
00000006        MOVE.L    #$6D616368,-(A7); 'mach'
0000000C        PEA       $FFFC(A6)
00000010        JSR       $0000(A5)
00000014        MOVE.W    (A7)+,$FFFA(A6)

Unless something fishy's going on, there's no test for _Gestalt.
- --
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 Kzoo randomly kills all my mail;  if I don't acknowledge, try resending.

+++++++++++++++++++++++++++

From: [e-mail] (Pete Resnick)
Organization: University of Illinois at Urbana
Date: Fri, 13 Mar 1992 00:47:19 GMT

[e-mail] (Jamie R. McCarthy) writes:

>    OSErr theOSErr; long r;
>    theOSErr = Gestalt(gestaltMachineType, &r);

>00000004        CLR.W     -(A7)
>00000006        MOVE.L    #$6D616368,-(A7); 'mach'
>0000000C        PEA       $FFFC(A6)
>00000010        JSR       $0000(A5)
                 ^^^^^^^^^^^^^^^^^^^
>00000014        MOVE.W    (A7)+,$FFFA(A6)

>Unless something fishy's going on, there's no test for _Gestalt.

The JSR there is your test for Gestalt. It is going to jump to some
glue which will be added at link time, which is why it is set to
0 off of A5. If it was using the trap instead of the glue, you would
have seen "DC.W $A1AD" instead.

pr
- --
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Organization: Royal Institute of Technology, Stockholm, Sweden
Date: Fri, 13 Mar 1992 16:48:44 GMT

.kzoo.edu> [e-mail] (Jamie R. McCarthy) writes:

   With <MacHeaders> in the prefix, I gave the disassembler:

   #include <GestaltEqu.h>
   int fred(void);
   int fred()
   {
       OSErr theOSErr; long r;
       theOSErr = Gestalt(gestaltMachineType, &r);
   }

   ...and it told me:

   00000004        CLR.W     -(A7)
   00000006        MOVE.L    #$6D616368,-(A7); 'mach'
   0000000C        PEA       $FFFC(A6)
   00000010        JSR       $0000(A5)
   00000014        MOVE.W    (A7)+,$FFFA(A6)

   Unless something fishy's going on, there's no test for _Gestalt.


If it DIDN'T check for the trap, that JSR would have been the trap
number. Now it's a JSR, because the check for the trap is in the
glue code (MacTraps)

- --
This signature is placed into the Public Domain by Jon W{tte ([e-mail])
                     - The worlds only romantic cynic -

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 13 Mar 92 17:01:21 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.kzoo.edu> [e-mail] (Jamie R. McCarthy) writes:

   >The _Gestalt glue checks for the presence of the [Gestalt] trap...

   Only if you're in MPW, remember.  Think C users must do the check.


You haven't upgraded Think C lately, have you ? Think C 5.0 glue
does most definately check for the trap.

- --
This signature is placed into the Public Domain by Jon W{tte ([e-mail])
                     - The worlds only romantic cynic -

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 20 Mar 92 20:20:16 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Jamie R. McCarthy) writes:
>
> [e-mail] writes:
> >
> >The _Gestalt glue checks for the presence of the [Gestalt] trap...
>
> Only if you're in MPW, remember.  Think C users must do the check.

I just built a small test program in Think C 5.0, and it does in deed
check for the presence of the Gestalt Trap.  Think uses the MPW libraries
from Apple for toolbox interfaces.


- -----------------------------------------------------------------------
Jim Reekes, E.O.             |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 24 Mar 92 04:50:22 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Nick
Rothwell) writes:
>
> In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
>
>    The unofficial and official DTS standpoint is that *never* assume that
>    an FPU is installed. Use Gestalt to check for this, now and forever.
>
> Er, but: can you always assume that *Gestalt* is installed on all
> machines? :-)

Inofficially speaking 6.0.4 upwards and A/UX 2.0 onwards. Yes, it does
not cover 128k Macs.

Cheers,
Kent
- --
Kent Sandvik/DTS - Dynamic Language Evangelist.
Opinions expressed are private, and not owned by any company,
organization or group. Happy happy, joy joy!

+++++++++++++++++++++++++++

From: [e-mail] (Chuq Von Rospach)
Date: 24 Mar 92 05:32:42 GMT
Organization: I is a writur

[e-mail] (Kent Sandvik) writes:

>In article <[e-mail]>, [e-mail] (Nick
>Rothwell) writes:
>> Er, but: can you always assume that *Gestalt* is installed on all
>> machines? :-)

>Inofficially speaking 6.0.4 upwards and A/UX 2.0 onwards. Yes, it does
>not cover 128k Macs.

The blessed way of handling this is to use GetTrapAddress() on Gestalt and
see if it's defined. If it is, use Gestalt(). If it's not, then you know
you've got an old release of the OS.

Check out the Mark book, or the "Programming 7.0" book from Addison-Wesley
for examples of how to do this cleanly (or I think there's a tech note, or
maybe someone will post a code fragment. I would, if I had it handy)

- --
            Chuq "IMHO" Von Rospach, Enterprise Products Support
            [e-mail] | GEnie:CHUQ & MAC.BIGOT | ALink:CHUQ
               Book Reviewer, Amazing Stories =+= Member, SFWA
           Editor, OtherRealms =+= #include <standard/disclaimer.h>

A fact is a fact. An opinion is an opinion. Just because your opinion
disagrees with the facts doesn't mean the facts are wrong.

+++++++++++++++++++++++++++

From: [e-mail] (Jim Reekes)
Date: 25 Mar 92 18:54:47 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:
>
> In article <[e-mail]>, [e-mail] (Chuq Von Rospach) writes:
> >
> > [e-mail] (Kent Sandvik) writes:
> >
> > >In article <[e-mail]>, [e-mail] (Nick
> > >Rothwell) writes:
> > >> Er, but: can you always assume that *Gestalt* is installed on all
> > >> machines? :-)
> >
> > >Inofficially speaking 6.0.4 upwards and A/UX 2.0 onwards. Yes, it does
> > >not cover 128k Macs.
> >
> > The blessed way of handling this is to use GetTrapAddress() on Gestalt and
> > see if it's defined. If it is, use Gestalt(). If it's not, then you know
> > you've got an old release of the OS.
>
> IM VI-3 has now the general information about Gestalt, TN129 will
> only document changes which are not reflected in IM.
>
> Here's the code from IM VI for detection of Gestalt:
>
> FUNCTION GestaltAvailable: Boolean;
> CONST
>    _Gestalt = $A1AD;
>
> BEGIN
>    GestaltAvailable := TrapAvailable(_Gestalt);
> END
>
> ...and IM mentions that MPW 3.2 has glue for detection of Gestalt
> when you call Gestalt functions, but those are not available for
> asm hacking (naturally).

They most certainly are available for assembly coding.  Instead of calling
the trap _Gestalt, you simply JSR GESTALT.  This will then call
the glue/library routine that is the same thing high level programmers use.

This libarary routine will first check if the _Gestalt trap is available.
If you are using the JSR method in assembly, or calling Gestalt from a
high level language you do not need to check if the trap is implemented.
Unless you compile you Pascal or C program with -d SystemSevenOrLater.
In this case, you are using the inline version of the interface and this
does not use the glue routine.

- -----------------------------------------------------------------------
Jim Reekes, E.O.             |     Macintosh Toolbox Engineering
                             |          Sound Manager Expert
Apple Computer, Inc.         | "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 81-KS |   not necessarily represent those of my
Cupertino, CA 95014          |       employer, Apple Computer Inc."

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 25 Mar 92 17:29:39 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Chuq Von Rospach) writes:
>
> [e-mail] (Kent Sandvik) writes:
>
> >In article <[e-mail]>, [e-mail] (Nick
> >Rothwell) writes:
> >> Er, but: can you always assume that *Gestalt* is installed on all
> >> machines? :-)
>
> >Inofficially speaking 6.0.4 upwards and A/UX 2.0 onwards. Yes, it does
> >not cover 128k Macs.
>
> The blessed way of handling this is to use GetTrapAddress() on Gestalt and
> see if it's defined. If it is, use Gestalt(). If it's not, then you know
> you've got an old release of the OS.

IM VI-3 has now the general information about Gestalt, TN129 will
only document changes which are not reflected in IM.

Here's the code from IM VI for detection of Gestalt:

FUNCTION GestaltAvailable: Boolean;
CONST
   _Gestalt = $A1AD;

BEGIN
   GestaltAvailable := TrapAvailable(_Gestalt);
END

..and IM mentions that MPW 3.2 has glue for detection of Gestalt
when you call Gestalt functions, but those are not available for
asm hacking (naturally).

Cheers,
Kent

- --
Kent Sandvik/DTS - Dynamic Language Evangelist.
Opinions expressed are not private, and not owned by any company, organization
or group. Happy happy, joy joy!

+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: 27 Mar 92 15:07:02 GMT
Organization: ICE Engineering, Inc.


Did anyone ever answer the original question?

I know that Apple says, you can not, indeed SHOULD not, determine
if MultiFinder is running. Well.... That is nice until you *need* to
know if MF is running (I have found only one case so far).

Solution: I have devised a very simple method that seems to work.
          I simply scan the Apple Menu Items for the word "MultiFinder",
          which seems to be in the "About MultiFinder" for all Systems.
          Of course, with System Seven the issue goes away, and so
          does the "About MultiFinder" :)

tim.


tim endres - [e-mail]  -or-  uupsi!tbomb!time
ICE Engineering, Inc. - Phone [phone] - FAX [phone]
8840 Main Street, Whitmore Lake, MI  48189
USENET - a slow moving self parody... ph

+++++++++++++++++++++++++++

From: [e-mail] (Juri Munkki)
Date: 28 Mar 92 09:31:19 GMT
Organization: Helsinki University of Technology, Finland

In article <[e-mail]> [e-mail] (Tim Endres) writes:
>Solution: I have devised a very simple method that seems to work.
>          I simply scan the Apple Menu Items for the word "MultiFinder",
>          which seems to be in the "About MultiFinder" for all Systems.
>          Of course, with System Seven the issue goes away, and so
>          does the "About MultiFinder" :)

It might work until someone goes and changes that menu item to something
like "Tietoja: moniajojarjestelma". They haven't done that here, but I
suppose that someone must have changed it, since it is possible.

Relying on a menu string to exist is an extremely bad practise.

   ____________________________________________________________________________
  / Juri Munkki        /  Helsinki University of Technology   /  Wind  / Project /
 / [e-mail]  /  Computing Center Macintosh Support  /  Surf  / Arashi  /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: 28 Mar 92 23:56:46 GMT
Organization: ICE Engineering, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Juri Munkki) writes:
> In article <[e-mail]> [e-mail] (Tim Endres) writes:
> >Solution: I have devised a very simple method that seems to work.
> >          I simply scan the Apple Menu Items for the word "MultiFinder",
> >          which seems to be in the "About MultiFinder" for all Systems.
> >          Of course, with System Seven the issue goes away, and so
> >          does the "About MultiFinder" :)
>
> It might work until someone goes and changes that menu item to something
> like "Tietoja: moniajojarjestelma". They haven't done that here, but I
> suppose that someone must have changed it, since it is possible.
>
> Relying on a menu string to exist is an extremely bad practise.

And having your code completely broken because you can not determine
if the _Launch trap is going to return or not is even worse... As
I originally posted:

    I know that Apple says, you can not, indeed SHOULD not, determine
    if MultiFinder is running.

However, there are cases in which customers wish to break the rules
with the understanding that they better not change the menu item :)
Again, this is only for cases in which the programmer understands
the implications.

tim.


tim endres - [e-mail]  -or-  uupsi!tbomb!time
ICE Engineering, Inc. - Phone [phone] - FAX [phone]
8840 Main Street, Whitmore Lake, MI  48189
USENET - a slow moving self parody... ph

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Organization: The Royal Society for Putting Things on Top of Other Things
Date: Sun, 29 Mar 1992 07:25:14 GMT

In article <[e-mail]> [e-mail] (Tim Endres) writes:
>And having your code completely broken because you can not determine
>if the _Launch trap is going to return or not is even worse... As
>I originally posted:

There is a Gestalt selector that returns this specific piece of
information.  I don't know if the Gestalt glue will emulate that particular
selector, but even if it does not, at least under System 6.0.4 or newer you
_don't_ need to check for Multifinder in this particular situation.


- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s++ e+ h- pv     |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: 27 Mar 92 15:07:02 GMT
Organization: ICE Engineering, Inc.


Did anyone ever answer the original question?

I know that Apple says, you can not, indeed SHOULD not, determine
if MultiFinder is running. Well.... That is nice until you *need* to
know if MF is running (I have found only one case so far).

Solution: I have devised a very simple method that seems to work.
          I simply scan the Apple Menu Items for the word "MultiFinder",
          which seems to be in the "About MultiFinder" for all Systems.
          Of course, with System Seven the issue goes away, and so
          does the "About MultiFinder" :)

tim.


tim endres - [e-mail]  -or-  uupsi!tbomb!time
ICE Engineering, Inc. - Phone [phone] - FAX [phone]
8840 Main Street, Whitmore Lake, MI  48189
USENET - a slow moving self parody... ph

+++++++++++++++++++++++++++

From: [e-mail] (Juri Munkki)
Date: 28 Mar 92 09:31:19 GMT
Organization: Helsinki University of Technology, Finland

In article <[e-mail]> [e-mail] (Tim Endres) writes:
>Solution: I have devised a very simple method that seems to work.
>          I simply scan the Apple Menu Items for the word "MultiFinder",
>          which seems to be in the "About MultiFinder" for all Systems.
>          Of course, with System Seven the issue goes away, and so
>          does the "About MultiFinder" :)

It might work until someone goes and changes that menu item to something
like "Tietoja: moniajojarjestelma". They haven't done that here, but I
suppose that someone must have changed it, since it is possible.

Relying on a menu string to exist is an extremely bad practise.

   ____________________________________________________________________________
  / Juri Munkki        /  Helsinki University of Technology   /  Wind  / Project /
 / [e-mail]  /  Computing Center Macintosh Support  /  Surf  / Arashi  /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: 28 Mar 92 23:56:46 GMT
Organization: ICE Engineering, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Juri Munkki) writes:
> In article <[e-mail]> [e-mail] (Tim Endres) writes:
> >Solution: I have devised a very simple method that seems to work.
> >          I simply scan the Apple Menu Items for the word "MultiFinder",
> >          which seems to be in the "About MultiFinder" for all Systems.
> >          Of course, with System Seven the issue goes away, and so
> >          does the "About MultiFinder" :)
>
> It might work until someone goes and changes that menu item to something
> like "Tietoja: moniajojarjestelma". They haven't done that here, but I
> suppose that someone must have changed it, since it is possible.
>
> Relying on a menu string to exist is an extremely bad practise.

And having your code completely broken because you can not determine
if the _Launch trap is going to return or not is even worse... As
I originally posted:

    I know that Apple says, you can not, indeed SHOULD not, determine
    if MultiFinder is running.

However, there are cases in which customers wish to break the rules
with the understanding that they better not change the menu item :)
Again, this is only for cases in which the programmer understands
the implications.

tim.


tim endres - [e-mail]  -or-  uupsi!tbomb!time
ICE Engineering, Inc. - Phone [phone] - FAX [phone]
8840 Main Street, Whitmore Lake, MI  48189
USENET - a slow moving self parody... ph

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Organization: The Royal Society for Putting Things on Top of Other Things
Date: Sun, 29 Mar 1992 07:25:14 GMT

In article <[e-mail]> [e-mail] (Tim Endres) writes:
>And having your code completely broken because you can not determine
>if the _Launch trap is going to return or not is even worse... As
>I originally posted:

There is a Gestalt selector that returns this specific piece of
information.  I don't know if the Gestalt glue will emulate that particular
selector, but even if it does not, at least under System 6.0.4 or newer you
_don't_ need to check for Multifinder in this particular situation.


- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s++ e+ h- pv     |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: 29 Mar 92 19:40:49 GMT
Organization: ICE Engineering, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (JohnC) writes:
> In article <[e-mail]> [e-mail] (Tim Endres) writes:
> >And having your code completely broken because you can not determine
> >if the _Launch trap is going to return or not is even worse... As
> >I originally posted:
>
> There is a Gestalt selector that returns this specific piece of
> information.  I don't know if the Gestalt glue will emulate that particular
> selector, but even if it does not, at least under System 6.0.4 or newer you
> _don't_ need to check for Multifinder in this particular situation.
>

Not true! On some systems the Gestalt selector you refer to (gestaltOSAttr,
gestaltLaunchCanReturn BIT) is true EVEN when Finder is running.
This has caused me great pain under systems as late as 6.0.7!

tim.


tim endres - [e-mail]  -or-  uupsi!tbomb!time
ICE Engineering, Inc. - Phone [phone] - FAX [phone]
8840 Main Street, Whitmore Lake, MI  48189
USENET - a slow moving self parody... ph

+++++++++++++++++++++++++++

From: [e-mail] (Quinn "The Eskimo!")
Organization: The University of Western Australia
Date: Mon, 30 Mar 1992 03:03:21 GMT

In article <[e-mail]>, [e-mail] (Tim Endres) writes:
>
> In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (JohnC) writes:
> >
> > There is a Gestalt selector that returns this specific piece of
> > information.  I don't know if the Gestalt glue will emulate that particular
> > selector, but even if it does not, at least under System 6.0.4 or newer you
> > _don't_ need to check for Multifinder in this particular situation.
> >
>
> Not true! On some systems the Gestalt selector you refer to (gestaltOSAttr,
> gestaltLaunchCanReturn BIT) is true EVEN when Finder is running.
> This has caused me great pain under systems as late as 6.0.7!

And if you mix your MultiFinders and your systems (for example MultiFinder 6.1b9
and System 6.0.7) then the gestaltLaunchCanReturn bit returns false even if
launch will return.  Very annoying that one.

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia


+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Organization: University of Illinois at Urbana-Champaign
Date: Mon, 30 Mar 1992 21:57:14 GMT

[e-mail] (Tim Endres) writes:
>          I simply scan the Apple Menu Items for the word "MultiFinder",
>          which seems to be in the "About MultiFinder" for all Systems.
>          Of course, with System Seven the issue goes away, and so
>          does the "About MultiFinder" :)

Try scanning the apple menu for the name of your application instead.
This will only fail if a) somebody has a DA named the same as your App
[pretty darn unlikely, and you could check for it anyway] or b) if
somebody renames your app while it's running [in which case they deserve
whatever they get]. This sidesteps the localization issue.

- --
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner

+++++++++++++++++++++++++++

From: [e-mail] (Phil Shapiro)
Date: 31 Mar 92 03:48:55 GMT
Organization: Symantec Corp.

>>>>> On Mon, 30 Mar 1992 21:57:14 GMT, [e-mail] (Steve Dorner) said:

 > Try scanning the apple menu for the name of your application
 > instead.  This will only fail if a) somebody has a DA named the
 > same as your App [pretty darn unlikely, and you could check for it
 > anyway] or b) if somebody renames your app while it's running [in
 > which case they deserve whatever they get]. This sidesteps the
 > localization issue.

Why not just test for the _OSDispatch (nee _JugglerDispatch) trap? For
example:

    #define OSDispatch  0xA88F
    #define UnImplTrap  0xA09F

    if (NGetTrapAddress(OSDispatch, ToolTrap) ==
        NGetTrapAddress(UnImplTrap, ToolTrap)) {
        // MF isn't present
    }
    else {
        // MF is present
    }

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: 31 Mar 92 13:43:31 GMT
Organization: ICE Engineering, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Phil Shapiro) writes:
> Why not just test for the _OSDispatch (nee _JugglerDispatch) trap? For
> example:
>
>    < code to check for trap deleted >
>

Finder can still be running with this trap present...


tim endres - [e-mail]  -or-  uupsi!tbomb!time
ICE Engineering, Inc. - Phone [phone] - FAX [phone]
8840 Main Street, Whitmore Lake, MI  48189
USENET - a slow moving self parody... ph

+++++++++++++++++++++++++++

From: [e-mail] (Pete Gontier)
Date: 3 Apr 92 02:26:36 GMT


 TE> From: [e-mail] (Tim Endres)
 TE> In article <[e-mail]>
 TE> (comp.sys.mac.programmer), [e-mail] (Phil Shapiro)
 TE> writes:
 TE> > Why not just test for the _OSDispatch (nee _JugglerDispatch) trap? For
 TE> > example:
 TE> >
 TE> >    < code to check for trap deleted >
 TE>
 TE> Finder can still be running with this trap present...

Tim, I *know* this isn't true, unless something really strange has happened
in System 6.0.8 that I don't know about. I've watched MultiFinder implement
the trap. I've implemented it myself (by mistake) under Finder and watched
Apple apps check for MultiFinder by comparing my patch address with the
unimplemented trap address. What makes you say this?

+++++++++++++++++++++++++++

From: [e-mail] (Tim Endres)
Date: 3 Apr 92 14:24:02 GMT
Organization: ICE Engineering, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Pete Gontier) writes:
>  TE> From: [e-mail] (Tim Endres)
>  TE> In article <[e-mail]>
>  TE> (comp.sys.mac.programmer), [e-mail] (Phil Shapiro)
>  TE> writes:
>  TE> > Why not just test for the _OSDispatch (nee _JugglerDispatch) trap? For
>  TE> > example:
>  TE> >
>  TE> >    < code to check for trap deleted >
>  TE>
>  TE> Finder can still be running with this trap present...
>
> Tim, I *know* this isn't true, unless something really strange has happened
> in System 6.0.8 that I don't know about. I've watched MultiFinder implement
> the trap. I've implemented it myself (by mistake) under Finder and watched
> Apple apps check for MultiFinder by comparing my patch address with the
> unimplemented trap address. What makes you say this?

A mistake made me say it (no! a little daemon made me do it! :).
Actually, it turns out that the code I had that made me think this
was broke. Therefore, I take back all I said and submit myself for
corrective action!

tim.


tim endres - [e-mail]  -or-  uupsi!tbomb!time
ICE Engineering, Inc. - Phone [phone] - FAX [phone]
8840 Main Street, Whitmore Lake, MI  48189
USENET - a slow moving self parody... ph

+++++++++++++++++++++++++++

From: [e-mail] (Amanda Walker)
Date: 3 Apr 92 01:26:24 GMT
Organization: Visix Software Inc., Reston, VA

[e-mail] (Phil Shapiro) writes:
> Why not just test for the _OSDispatch (nee _JugglerDispatch) trap?

I believe that it is always present in Systems > 6.0.5...

Amanda Walker                        [e-mail]
Project Leader, Multiplatform Software Development
Visix Software Inc.                     [phone]
- --
"If a man does not keep pace with his companions, perhaps it is because he
 hears a different drummer.  Let him march to the music he hears, be it
 however measured or far away."        --Henry David Thoreau

+++++++++++++++++++++++++++

From: [e-mail] (Tommy Nordgren)
Date: 6 Apr 92 15:28:59 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

There is one very reliable way. Check for the presence of the OSDispatch trap,
used to allocate temporary memory from multifinder.

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 6 Apr 92 21:16:58 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.se> [e-mail] (Tommy Nordgren) writes:

   There is one very reliable way. Check for the presence of the OSDispatch
   trap, used to allocate temporary memory from multifinder.

That is still not a reliable way. It tells you wether you can use
MF temp mem. It does NOT tell you wether _Launch will return.

However, the whole question is esoteric, since these days there's
no need to concern oneself about that; _LaunchApplication doesn't
need a wdRefNum, and DOES return. And if you need launching
capabilities, there's no reason not to use system software that's
been out for a ywar and the upgrade to which is free.

- --
[e-mail]; Jon W{tte, the Diplomat - NOT!

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 6 Apr 92 23:36:45 GMT
Organization: Apple Co.

> [going on about MultiFinder & Launch...]

Here's a totally skanky thing to do that no one should recommend, but might
solve your problems.  Taken in concert with the system version number, which
you are undoubtedly looking at, this should provide you with the knowledge
you want.  Simply look for the MultiFinder file in the System folder (the
name is actually stored in the System itself as a STR or STR# if you want
to be international.  If it is missing on systems that need it, it's not
running.  If it is there, open it.  If you get an error MultiFinder is
running, otherwise it is not running.

How's that for a skanky hack?  Talk about assuming things...

Jon

Few things are harder to put up with than the annoyance of a good example.

+++++++++++++++++++++++++++

From: [e-mail] (Tommy Nordgren)
Date: 6 Apr 92 15:28:59 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

There is one very reliable way. Check for the presence of the OSDispatch trap,
used to allocate temporary memory from multifinder.

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 6 Apr 92 21:16:58 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.se> [e-mail] (Tommy Nordgren) writes:

   There is one very reliable way. Check for the presence of the OSDispatch
   trap, used to allocate temporary memory from multifinder.

That is still not a reliable way. It tells you wether you can use
MF temp mem. It does NOT tell you wether _Launch will return.

However, the whole question is esoteric, since these days there's
no need to concern oneself about that; _LaunchApplication doesn't
need a wdRefNum, and DOES return. And if you need launching
capabilities, there's no reason not to use system software that's
been out for a ywar and the upgrade to which is free.

- --
[e-mail]; Jon W{tte, the Diplomat - NOT!

+++++++++++++++++++++++++++

From: [e-mail] (Jon Pugh)
Date: 6 Apr 92 23:36:45 GMT
Organization: Apple Co.

> [going on about MultiFinder & Launch...]

Here's a totally skanky thing to do that no one should recommend, but might
solve your problems.  Taken in concert with the system version number, which
you are undoubtedly looking at, this should provide you with the knowledge
you want.  Simply look for the MultiFinder file in the System folder (the
name is actually stored in the System itself as a STR or STR# if you want
to be international.  If it is missing on systems that need it, it's not
running.  If it is there, open it.  If you get an error MultiFinder is
running, otherwise it is not running.

How's that for a skanky hack?  Talk about assuming things...

Jon

Few things are harder to put up with than the annoyance of a good example.

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 9 Apr 92 16:41:56 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Jon Pugh) writes:
>> [going on about MultiFinder & Launch...]
>
> Here's a totally skanky thing to do that no one should recommend, but might
> solve your problems.  Taken in concert with the system version number, which
> you are undoubtedly looking at, this should provide you with the knowledge
> you want.  Simply look for the MultiFinder file in the System folder (the
> name is actually stored in the System itself as a STR or STR# if you want
> to be international.  If it is missing on systems that need it, it's not
> running.  If it is there, open it.  If you get an error MultiFinder is
> running, otherwise it is not running.
>
> How's that for a skanky hack?  Talk about assuming things...

Certainly is skanky. I don't recall the name of the MultiFinder file
being stored anywhere in the System though; I thought only the Finder had to
know what its name was, so it could set it as the startup application.

But why bother thinking up all these elaborate techniques? Just check
for the presence of the OSDispatch/JugglerDispatch trap ($A88F). It's the
technique Apple themselves use. You can't get any simpler, or more reliable,
than that.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

+++++++++++++++++++++++++++

From: [e-mail] (Ivan M CaveroBelaunde)
Date: 9 Apr 92 12:09:19 GMT
Organization: The World Public Access UNIX, Brookline, MA

A technique that I've seen mentioned before is using Gestalt on gestaltOSAttr
('os  '). One of the flags returned specify whether a Launch trap can return
to the caller (launchCanReturn or somesuch). I'm not sure, however, which
is the minimum system that supports this Gestalt selector.

Hope this helps,
- -Ivan
- ---
Ivan Cavero Belaunde
DiVA Corporation

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Date: 9 Apr 92 19:27:23 GMT
Organization: Taligent, Inc.

In article <[e-mail]>, [e-mail] (Lawrence
D'Oliveiro, Waikato University) writes:
>
> But why bother thinking up all these elaborate techniques? Just check
> for the presence of the OSDispatch/JugglerDispatch trap ($A88F). It's the
> technique Apple themselves use. You can't get any simpler, or more reliable,

As I recall, checking for the MF Temporary Memory calls requires more than
testing for the trap.  Didn't you also have to check a low-memory global to rule
out Switcher?
- --
Larry Rosenstein
Taligent, Inc.
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 10 Apr 92 22:56:50 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Lawrence
D'Oliveiro, Waikato University) writes:
>
> Certainly is skanky. I don't recall the name of the MultiFinder file
> being stored anywhere in the System though; I thought only the Finder had to
> know what its name was, so it could set it as the startup application.
>
> But why bother thinking up all these elaborate techniques? Just check
> for the presence of the OSDispatch/JugglerDispatch trap ($A88F). It's the
> technique Apple themselves use. You can't get any simpler, or more reliable,
> than that.

Sigh, I guess DTS is speaking in vain about not checking for MF presence.

Cheers,
Kent

+++++++++++++++++++++++++++

From: [e-mail] (Pete Gontier)
Date: Fri, 10 Apr 1992 23:23:05 -0500

 JW> From: [e-mail] (Jon W{tte)

 JW> [e-mail] (Tommy Nordgren) writes:

 JW> There is one very reliable way. Check for the presence of the
 JW> OSDispatch trap, used to allocate temporary memory from multifinder.
 JW>
 JW> That is still not a reliable way. It tells you wether you can use
 JW> MF temp mem. It does NOT tell you wether _Launch will return.

It's not *officially* reliable. If System 6.0.9...6.0.10... implement
_OSDispatch when MultiFinder is not running, then you're right, this will
not be a reliable method.

However, a lot of Apple's own utilities use this method and would all have
to be tweaked. And *why* would Apple do such a thing? To foil this scheme?
System 6 is pretty much frozen as far as this sort of OS feature goes.
So, as far as I'm concerned, it's a reliable method. It even works under
System 7, though it's not necessary, as you go on to say...

 JW> However, the whole question is esoteric, since these days there's
 JW> no need to concern oneself about that; _LaunchApplication doesn't
 JW> need a wdRefNum, and DOES return. And if you need launching
 JW> capabilities, there's no reason not to use system software that's
 JW> been out for a ywar and the upgrade to which is free.

My company (Kiwi, not EC) is marketing a System 7 only utility. We've been
making some phone calls to registered users. A surprisingly large percentage
of them have actually *gone back to System 6* for compatibility reasons.
(Obviously those reasons haven't to do with our utility -- often it's a
printer driver or some fax INIT or something else they can't do without.)
System 6 is definitely not dead, folks.

+++++++++++++++++++++++++++

From: [e-mail] (Pete Gontier)
Date: Fri, 10 Apr 1992 23:29:47 -0500

 JP> From: [e-mail] (Jon Pugh)

 JP> Simply look for the MultiFinder file in the System folder (the
 JP> name is actually stored in the System itself as a STR or STR# if you want
 JP> to be international.) If it is missing on systems that need it, it's not
 JP> running.  If it is there, open it.  If you get an error MultiFinder is
 JP> running, otherwise it is not running.

I used to do this when I wanted this info. Then I found out that you
could move a file between directories while it was open. MultiFinder's
icon could be sitting on the desktop and MF would happily keep running.

Obviously, no sane user would do such a thing, right? But when it means
crashing because you didn't think MF was running, well, it gets to look
a little less than paranoid. Besides, a user might think removing MF
from the System Folder has the same effect as removing an INIT, and he'd
be right, sort of.

Checking for the existence of _OSDispatch is much better. At least then
when Apple changes it in System 6.0.19, you'll know which system version
you break on.

+++++++++++++++++++++++++++

From: [e-mail] (Pete Gontier)
Date: Fri, 10 Apr 1992 23:50:04 -0500

 IM> From: [e-mail] (Ivan M CaveroBelaunde)

 IM> A technique that I've seen mentioned before is using Gestalt on
 IM> gestaltOSAttr ('os  '). One of the flags returned specify whether
 IM> a Launch trap can return to the caller (launchCanReturn or somesuch).

This Gestalt selector is supported on any machine running the Process Manager,
which currently is found only in System 7.

+++++++++++++++++++++++++++

From: [e-mail] (Quinn "The Eskimo!")
Organization: The University of Western Australia
Date: Mon, 13 Apr 1992 03:53:35 GMT

In article <[e-mail]>,... writes:
>
>  IM> From: [e-mail] (Ivan M CaveroBelaunde)
>
>  IM> A technique that I've seen mentioned before is using Gestalt on
>  IM> gestaltOSAttr ('os  '). One of the flags returned specify whether
>  IM> a Launch trap can return to the caller (launchCanReturn or somesuch).
>
> This Gestalt selector is supported on any machine running the Process Manager,
> which currently is found only in System 7.

Rong.  It's *definitely* supported under System 6.0.7 (with MultiFinder).
I know! I have the technology! I have GestaltDA sitting in front of me!

Quinn "The Eskimo!"   <[e-mail]>  "Real Coke, Diet .sig"
Department of Computer Science, The University of Western Australia


+++++++++++++++++++++++++++

From: [e-mail] (Tommy Nordgren)
Date: 13 Apr 92 13:11:06 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In article <[e-mail]>, [e-mail] (Larry Rosenstein) writes:
|> In article <[e-mail]>, [e-mail] (Lawrence
|> D'Oliveiro, Waikato University) writes:
|> >
|> > But why bother thinking up all these elaborate techniques? Just check
|> > for the presence of the OSDispatch/JugglerDispatch trap ($A88F). It's the
|> > technique Apple themselves use. You can't get any simpler, or more reliable,
|>
|> As I recall, checking for the MF Temporary Memory calls requires more than
|> testing for the trap.  Didn't you also have to check a low-memory global to rule
|> out Switcher?
|> --
|> Larry Rosenstein
|> Taligent, Inc.
|> [e-mail]
The Switcher is **** OBSOLETE ***** there is probebly NO NEED to check for it.

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 14 Apr 92 05:27:24 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Larry Rosenstein) writes:
> In article <[e-mail]>, [e-mail] (Lawrence
> D'Oliveiro, Waikato University) writes:
>>
>> But why bother thinking up all these elaborate techniques? Just check
>> for the presence of the OSDispatch/JugglerDispatch trap ($A88F). It's the
>> technique Apple themselves use. You can't get any simpler, or more reliable,
>
> As I recall, checking for the MF Temporary Memory calls requires more than
> testing for the trap.  Didn't you also have to check a low-memory global to rule
> out Switcher?

Last I heard, Switcher didn't support JugglerDispatch, so unless you can
run both Switcher and MultiFinder at the same time, or there's been an update
to Switcher, the presence of this trap automatically rules out Switcher.








:-)








On a related note, I'd like to revive the term "Juggler" as a generic way
of referring to both the pre-System-7 MultiFinder and the System 7 Process
Manager. After all, "MultiFinder" seems a somewhat inappropriate term for
the latter. I know Apple couldn't use "Juggler" as a product name because
someone else had already trademarked it; but there's no problem with our using
it as a technical term, is there?

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 14 Apr 92 05:47:22 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Kent Sandvik) writes:
> Sigh, I guess DTS is speaking in vain about not checking for MF presence.

Sigh, I guess us poor programmers are speaking in vain when we keep repeating
all the old reasons for checking for MultiFinder. Here are a couple of obvious
ones:

* Determining whether you will keep running after launching another application
(other postings in this thread have indicated that the appropriate Gestalt
selector is unreliable);

* Determining whether the system heap is resizable, so applications with highly-
variable requirements for longer-term memory storage can do their allocation
there, and don't have to keep telling the user to readjust their partition
sizes.

All flames and lectures regarding the second reason will be autoforwarded to
/get/stuffed.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
This line intentionally left unfunny.

+++++++++++++++++++++++++++

From: [e-mail] (Pete Resnick)
Organization: University of Illinois at Urbana
Date: Tue, 14 Apr 1992 15:41:41 GMT

[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:

>* Determining whether you will keep running after launching another application
>(other postings in this thread have indicated that the appropriate Gestalt
>selector is unreliable);

OK, I've been following this entire thread and I still can't figure
this one out: Why would anyone *care* whether they will keep running
after they launch another application? I am just not sure what
functionality is being talked about.

pr
- --
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Phil Shapiro)
Date: 15 Apr 92 14:34:08 GMT
Organization: Symantec Corp.

>>>>> On 14 Apr 92 17:47:22 +1200, [e-mail] (Lawrence D'Oliveiro, Waikato University) said:

I guess I missed the earier discussions. Why can't you use Gestalt for
these features? Specific reasons or examples would be nice.

 > * Determining whether you will keep running after launching another
 > application (other postings in this thread have indicated that the
 > appropriate Gestalt selector is unreliable);

gestaltOSAttr, response bit gestaltLaunchCanReturn

 > * Determining whether the system heap is resizable, so applications
 > with highly- variable requirements for longer-term memory storage
 > can do their allocation there, and don't have to keep telling the
 > user to readjust their partition sizes.

gestaltOSAttr, response bit gestaltSysZoneGrowable

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 15 Apr 92 21:43:00 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail]
(Pete Resnick) writes:
>
> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>
> >* Determining whether you will keep running after launching another
application
> >(other postings in this thread have indicated that the appropriate Gestalt
> >selector is unreliable);
>
> OK, I've been following this entire thread and I still can't figure
> this one out: Why would anyone *care* whether they will keep running
> after they launch another application? I am just not sure what
> functionality is being talked about.

If you sub-launch an application, you would like to know if you have to go
through the effort of saving the current state of any open documents. For
instance, say MacWrite has the ability to sub-launch applications. When I select
that menu item, I don't want MacWrite to ask me if I want to save any open
documents if Multi-Finder is running and the Launch call will return
immediately.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (John Miller)
Date: 16 Apr 92 05:31:50 GMT
Organization: MIND LINK! - British Columbia, Canada

In message <[e-mail]>,
[e-mail] writes

> JP> From: [e-mail] (Jon Pugh)
>
> JP> Simply look for the MultiFinder file in the System folder (the
> JP> name is actually stored in the System itself as a STR or > JP> STR# if
you want to be international.) If it is missing
> JP> on systems that need it, it's not running.  If it is there,
> JP> open it.  If you get an error MultiFinder is running, otherwise
> JP> it is not running.
>
>I used to do this when I wanted this info. Then I found out that
>you could move a file between directories while it was open.
>MultiFinder's icon could be sitting on the desktop and MF
> would happily keep running.
>
>Obviously, no sane user would do such a thing, right? But when it

Actually, the multimedia computing lab at a local community
college kept the MultiFinder file on the desktop.  The Macs were
set to boot under UniFinder.  If the user wanted to run
MultiFinder, the Command-Option-Double-Click trick was used.
(Of course, if someone had asked me if this was possible, I would
have wisely proclaimed "Don't be silly:  the MultiFinder file
*has* to be in the System Folder.")

So this is one example where the test would fail.  I have no idea
how many installations might use this trick, but it seems
like that the type of thing that might make its way into the
Tips column of magazines or user groups newsletters.

John Miller
Symplex Systems


+++++++++++++++++++++++++++

From: [e-mail] (Daniel M. van der Zee (I89))
Date: 16 Apr 92 14:48:58 GMT
Organization: FWI, University of Amsterdam

Maybe we should create a group
     comp.sys.mac.programmer.find.out.if.multifinder.is.running

Daniel van der Zee
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Tim W Smith)
Date: 18 Apr 92 02:44:39 GMT
Organization: The Portal System (TM)

OK, here's a quick hack for checking for MF.  I haven't actually
tried it, though.

Add the size of the system heap and the size of the application heap.
If this is near the total size of memory, then assume no MF.  Otherwise,
assume MF.

                            Tim Smith

+++++++++++++++++++++++++++

From: [e-mail] (Jeremiah Blatz)
Date: 19 Apr 92 02:06:09 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Tim W Smith) writes:

> Add the size of the system heap and the size of the application heap.
> If this is near the total size of memory, then assume no MF.  Otherwise,
> assume MF.

Okay, what about all of us who need more memory than we have (ever
tried rotating a large, 600 dpi bitmap in Canvas on a Mac+ w/Sys. 7)?
We allocate enough memory to our big programs to be sure that they get
every byte of memory we have.

Jeremiah
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Joe Francis)
Date: 20 Apr 92 03:08:55 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Pete Resnick) writes:

> OK, I've been following this entire thread and I still can't figure
> this one out: Why would anyone *care* whether they will keep running
> after they launch another application? I am just not sure what
> functionality is being talked about.

I'll tack a cut at this one.  Suppose you have an application which can
fetch other applications from a public server, put them on the users
mac, and launch them.  Further suppose that a normal use of this
program would be to do this several times - ie, you don't just want to
always quit after doing this once.  Further suppose that your program
uses MacTCP to talk to another server that tells it what things it can
fetch/launch, and where they might be.

One thing you DON'T want to do with MacTCP is quit without closing out
your connections.  If you do, your user will do rude things to you
involving (but not limited to) sharp objects.  Thus it's important to
know whether _Launch will terminate your existence.

This is a real life example, by the way, taken from my current work.  I
check OSDispatch.  Do it for your kids.

(In fact, in order to support IAC under system 6, I even find out which
version of MultiFinder I've got, but that's another story...)

+++++++++++++++++++++++++++

From: [e-mail] (Tim W Smith)
Date: Sun, 19 Apr 92 23:35:51 PDT
Organization: The Portal System (TM)

> > Add the size of the system heap and the size of the application heap.
> > If this is near the total size of memory, then assume no MF.  Otherwise,
> > assume MF.
>
> Okay, what about all of us who need more memory than we have (ever
> tried rotating a large, 600 dpi bitmap in Canvas on a Mac+ w/Sys. 7)?
> We allocate enough memory to our big programs to be sure that they get
> every byte of memory we have.

What does this have to do with checking for MF?  If you are not running
MF, you get all the memory, so adding system heap + application heap
should give you something close to the total size of memory.

If you are running MF, then Finder will be taking up a couple of hundred
K of memory, so adding the system heap and the application heap should
come up short of total memory, no matter what you've set the application
size to.

                            Tim Smith

+++++++++++++++++++++++++++

From: [e-mail] (John H. Hall)
Date: 20 Apr 92 19:28:38 GMT
Organization: Los Alamos National Laboratory

>
> What does this have to do with checking for MF?  If you are not running
> MF, you get all the memory, so adding system heap + application heap
> should give you something close to the total size of memory.
>
> If you are running MF, then Finder will be taking up a couple of hundred
> K of memory, so adding the system heap and the application heap should
> come up short of total memory, no matter what you've set the application
> size to.
>
>                             Tim Smith
>
>
Don't some people in memory low situations (e.g. 4 MB MacPlus and system 7) have
an extension that closes Finder during an application launch. I thought I saw a
mention of one sometime back. This would probably mess up this attempt to
locate MF's presence.

+++++++++++++++++++++++++++

From: [e-mail] (Dean Yu)
Date: 21 Apr 92 16:47:03 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Tim W Smith) writes:
>
> OK, here's a quick hack for checking for MF.  I haven't actually
> tried it, though.
>
> Add the size of the system heap and the size of the application heap.
> If this is near the total size of memory, then assume no MF.  Otherwise,
> assume MF.
>

  This won't work if you're running MacsBug with a huge Debuggers Prefs
file, or other extensions that place themselves above BufPtr.

  -- Dean Yu
     Blue Meanie, Negative Ethnic Role Model, Window Cleaner,
      Skanky Hack Consultant, etc.
     Apple Computer, Inc.

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 23 Apr 92 17:13:18 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Keith Rollin) writes:
> In article <[e-mail]>, [e-mail]
> (Pete Resnick) writes:
>>
>> OK, I've been following this entire thread and I still can't figure
>> this one out: Why would anyone *care* whether they will keep running
>> after they launch another application? I am just not sure what
>> functionality is being talked about.
>
> If you sub-launch an application, you would like to know if you have to go
> through the effort of saving the current state of any open documents.

Yup. And here's another related reason, with more nasty consequences:

On systems not running MultiFinder, if you don't close a file before you quit,
it don't get closed.

Lawrence "found this out the hard way" D'Oliveiro

+++++++++++++++++++++++++++

From: [e-mail] (Jeremiah Blatz)
Date: 25 Apr 92 19:21:11 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Tim W Smith) writes:

> > Okay, what about all of us who need more memory than we have (ever
> > tried rotating a large, 600 dpi bitmap in Canvas on a Mac+ w/Sys. 7)?
> > We allocate enough memory to our big programs to be sure that they get
> > every byte of memory we have.
>
> What does this have to do with checking for MF?  If you are not running
> MF, you get all the memory, so adding system heap + application heap
> should give you something close to the total size of memory.

Sorry, I didn't mention that I quit the Finfer before launching any
RAM-hungry app. (via a tiny app. that launches an app. then quits).

Okay, here's my stab at checking for MF: present a dialog box at
program startup that apoligises (sp) for the inconvience and blames
Apple, then asks the user if they are running MultiFinder. If they
click "Yes" assume MF, If they click "No", no MF. You could add a
"Help" button explaining to the user that there will be a littlr
picture of a Macintosh on the right of the menu bar if they are running
MultiFinder.

Jeremiah

---------------------------

End of C.S.M.P. Digest
**********************